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A TCP Authentication Option Extension for NAT Traversal 


Abstract 


This document describes an extension to the TCP Authentication Option 
(TCP-AO) to support its use over connections that pass through 
Network Address Translators and/or Network Address and Port 
Translators (NATs/NAPTs). This extension changes the data used to 
compute traffic keys, but it does not alter TCP-AO’s packet 
processing or key generation algorithms. 


Status of This Memo 
This document is not an Internet Standards Track specification; it is 


published for examination, experimental implementation, and 
evaluation. 


This document defines an Experimental Protocol for the Internet 
community. This is a contribution to the RFC Series, independently 
of any other RFC stream. The RFC Editor has chosen to publish this 
document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6978. 


Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


This document describes an extension to the TCP Authentication Option 
(TCP-AO) [RFC5925] called TCP-AO-NAT to support its use in the 
presence of Network Address Translators and/or Network Address and 
Port Translators (NATs/NAPTs) [RFC2663]. These devices translate the 
source address and/or the source port number of a TCP connection. 
TCP-AO without TCP-AO-NAT extensions would be sensitive to these 
modifications and would discard authenticated segments. 


At least one potential application of TCP-AO-NAT is to support the 
experimental multipath TCP protocol [RFC6824], which uses multiple IP 
addresses to support a single TCP transfer. 


This document assumes detailed familiarity with TCP-AO [RFC5925]. As 
a preview, this document focuses on how TCP-AO generates traffic 
keys, and it does not otherwise alter the TCP-AO mechanism or that of 
its key generation [RFC5926]. 


2. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
When used in lower case, these words have their conventional meaning 
and do not convey the interpretations in RFC 2119. 
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3; 


Background 

TCP-AO generates traffic keys that are specific to a socket pair 
[RFC5925]. The following information is used to create a 
connection’s traffic keys. (Note that ’local’ and ’remote’ are 
interpreted as in TCP-AO [RFC5925].) 

o IP local address 

o IP remote address 

o TCP local port 

o TCP remote port 

o TCP local Initial Sequence Number (ISN) 

o TCP remote Initial Sequence Number (ISN) 

Of these fields, the remote ISN is not known for SYN segments and is 
excluded from the traffic key used to authenticate them. Otherwise, 
all fields are used in the traffic keys of all other segments. 

NATs and NAPTs (both referred to herein as "NATs", even if port 
translation is included) would interfere with these uses, because 


they alter the IP address and TCP port of the endpoint behind the NAT 
[RFC2663]. 


Extension to Allow NAT Traversal 


The premise of TCP-AO-NAT is that it might be useful to allow TCP-AO 
use in the presence of NATs, e.g., to protect client/server 
communication where clients are behind NATs. 


This document describes TCP-AO-NAT, an extension to TCP-AO that 
enables its use in the presence of NATs. This extension requires no 
modification to the TCP-AO header or packet processing, and it 
requires no modification to the algorithms used to generate traffic 
keys [RFC5926]. The change is limited to the data used to generate 
traffic keys only. 


In TCP-AO, "a Master Key Tuple (MKT) describes the TCP-AO properties 
to be associated with one or more connections" [RFC5925]. This 
includes the TCP connection identifier, the TCP option flag 
(indicating whether TCP options other than TCP-AO are included in the 
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Message Authentication Code (MAC) calculation), keying information, 
and other parameters. TCP-AO-NAT augments the MKT with two 
additional flags: 


o localNAT 
o remoteNAT 


TCP-AO implementations supporting TCP-AO-NAT MUST support both 
localNAT and remoteNAT flags. 


These flags indicate whether a segment’s local or remote 
(respectively) IP address and TCP port are zeroed before MAC 
calculation, either for creating the MAC to insert (for outgoing 
segments) or for calculating a MAC to validate against the value in 
the option. These flags modify TCP-AO processing rules as follows: 


o In TCP-AO-NAT, traffic keys are computed by zeroing the 
local/remote IP address and TCP port as indicated by the localNAT 
or remoteNAT flags. 


o In TCP-AO-NAT, MAC values are computed by zeroing the local/remote 
IP address and TCP port as indicated by the localNAT or remoteNAT 
flags. 


The use of these flags needs to match on both ends of the connection, 
just as with all other MKT parameters. 


52 Intended Use 


A host MAY use TCP-AO-NAT when it is behind a NAT, as determined 
using NAT discovery techniques, or when TCP-AO protection is desired 
but conventional TCP-AO fails to establish connections. 


A client behind a NAT MAY set localNAT=TRUE for MKTs supporting 
TCP-AO-NAT for outgoing connections. A server MAY set remoteNAT=TRUE 
for MKTs supporting TCP-AO-NAT for incoming connections. Peer-to- 
peer applications with dual NAT support, e.g., those traversing 
so-called ’symmetric NATs’ [RFC5389], MAY set both localNAT=TRUE and 
remoteNAT=TRUE for MKTs supporting TCP-AO-NAT bidirectionally. Once 
these flags are set in an MKT, they affect all connections that match 
that MKT. 


TCP-AO-NAT is intended for use only where coordinated between 
endpoints for connections that match the shared MKT parameters, as 
with all other MKT parameters. 
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Note that TCP-AO-NAT is not intended for use with services transiting 
Application Layer Gateways (ALGs), i.e., NATs that also translate 
in-band addresses, such as used in FTP or SIP. TCP-AO-NAT protects 
the contents of the TCP segments from modification and would 
(correctly) interpret such alterations as an attack on those 
contents. 


6. Security Considerations 


TCP-AO-NAT does not affect the security of connections that do not 
set either the localNAT or remoteNAT flags. Such connections are not 
affected themselves and are not affected by segments in other 
connections that set those flags. 


Setting either the localNAT or remoteNAT flags reduces the randomness 
of the input to the Key Derivation Function (KDF) used to generate 
the traffic keys. The largest impact occurs when using IPv4, which 
reduces the randomness from 2 IPv4 addresses, 2 ISNs, and both ports 
down to just the two ISNs when both flags are set. The amount of 
randomness in the IPv4 addresses and service port is likely to be 
small, and the randomness of the dynamic port is under debate and 
should not be considered substantial [RFC6056]. The KDF input 
randomness is thus expected to be dominated by that of the ISNs, so 
reducing it by either or both of the IPv4 addresses and ports is not 
expected to have a significant impact. 
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